917961 - crash in nsXPCWrappedJS::CallMethod via ImportMailThread, accessing/calling nsXPCWrappedJS off-main-thread after nsMsgFolderNotificationService::NotifyFolderDeleted. Mostly importing from Eudora and Outlook

Status: RESOLVED WORKSFORME

(MailNews Core :: Import, defect)

Description

[Wayne Mery (:wsmwk)]

This bug was filed from the Socorro interface and is 
report bp-4808782d-14a3-4e44-8a4a-17bf62130917.
=============================================================
~#1 crash - if you look at https://crash-stats.mozilla.com/query/?product=Thunderbird&version=Thunderbird%3A24.0&range_value=1&range_unit=weeks&date=09%2F18%2F2013+14%3A00%3A00&query_search=signature&query_type=contains&query=&reason=&release_channels=&build_id=&process_type=any&hang_type=any

0	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *)	js/xpconnect/src/XPCWrappedJS.cpp
1	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
2	xul.dll	SharedStub	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp
3	xul.dll	nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder *)	mailnews/base/src/nsMsgFolderNotificationService.cpp

Comment 1

[Wayne Mery (:wsmwk)]

bp-0fbf7d3b-7051-43dc-8dac-e02672130906 tb25.0a2

hg@0 149 /* void notifyFolderDeleted(in nsIMsgFolder aFolder); */
hg@0 150 NS_IMETHODIMP nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder *aFolder)
hg@0 151 {
sid1337@162 152 NOTIFY_MSGFOLDER_LISTENERS(folderDeleted, FolderDeleted, (aFolder));

Comment 2

[Wayne Mery (:wsmwk)]

Holding solid at #1 crash for TB24. And regression.

Oldest build ID found in 4 months of crashes is TB24 beta 20130814132443. Hard to say via crash-stats how much older the regression really is.

possible reproducible testcase bp-e7700aed-d2f9-419e-81ad-fdad62130920
" It always crashes when I try to import my Apple Mail "
0	XUL	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp
1	XUL	PrepareAndDispatch	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp
2	XUL	SharedStub	
3	XUL	nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder*)	mailnews/base/src/nsMsgFolderNotificationService.cpp
4	XUL	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	mailnews/base/util/nsMsgDBFolder.cpp
5	XUL	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	mailnews/base/util/nsMsgDBFolder.cpp
6	XUL	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	mailnews/base/util/nsMsgDBFolder.cpp
7	XUL	ImportMailThread	mailnews/import/src/nsImportMail.cpp

Comment 3

[Wayne Mery (:wsmwk)]

Do we need more than the stack  to move this topcrash to resolution?

Comment 4

[Wayne Mery (:wsmwk)]

 GetContextFromObjectOrDefault 
bp-a7d0e794-7a02-476d-bc1f-457422130921
frame 1 is nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *,unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *)

Comment 5

[Tracy Walker [:tracy]]

topcrash is being replaced by more precise keywords per https://bugzilla.mozilla.org/show_bug.cgi?id=927557#c3

Comment 6

[Matt]

In this support thread https://support.mozilla.org/en-US/questions/992982?  The fix was to shorten the path to the local folder that outlook express was imported to.

My assumption is the folder import does not have appropriate code to cope with path > 255 issues, but I have not looked and probably would not know it if I saw it anyway.

Where there is a comment for these they appear to relate to outlook or outlook express import. and lots of french and German.. both of which are fairly verbose languages

Outlook Express uses the folder.dbx file to manage it's folders, outlook uses a similar structure within the PST file so it is quite possible lots of these will appear as the 20 or so characters in the root path to the import folder in Thunderbird just do not exist in these other programs.

Comment 8

[Wayne Mery (:wsmwk)]

indeed Most crashes involve importing from Eudora and Outlook

#19 crash for version 31.6.0. 

bp-c98aa9c6-ff81-480e-bb6e-65b042150512
bp-bb0d2f1a-73f6-44ac-a538-d5eef2150420 (kevin)

bp-ac176623-8263-4a66-91ab-04aa82150430 is a rare example with a large stack
0 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp
1 	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp
2 	xul.dll	SharedStub	xpcom/reflect/xptcall/md/win32/xptcstubs_asm_x86_64.asm
3 	xul.dll	mozJSComponentLoader::ModuleEntry::GetFactory(mozilla::Module const&, mozilla::Module::CIDEntry const&)	js/xpconnect/loader/mozJSComponentLoader.cpp
4 	xul.dll	nsFactoryEntry::GetFactory()	xpcom/components/nsComponentManager.cpp
5 	xul.dll	nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**)	xpcom/components/nsComponentManager.cpp
6 	xul.dll	CallCreateInstance(char const*, nsISupports*, nsID const&, void**)	xpcom/glue/nsComponentManagerUtils.cpp
7 	xul.dll	nsCreateInstanceByContractID::operator()(nsID const&, void**)	xpcom/glue/nsComponentManagerUtils.cpp
8 	xul.dll	nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&)	xpcom/glue/nsCOMPtr.cpp
9 	xul.dll	nsMsgCompFields::nsMsgCompFields()	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/compose/src/nsMsgCompFields.cpp:63
10 	xul.dll	nsMsgCompFieldsConstructor	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/build/nsMailModule.cpp:552
11 	xul.dll	nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID const&, void**)	xpcom/components/nsComponentManager.cpp
12 	xul.dll	CallCreateInstance(nsID const&, nsISupports*, nsID const&, void**)	xpcom/glue/nsComponentManagerUtils.cpp
13 	xul.dll	nsOutlookCompose::CreateComponents()	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookCompose.cpp:246
14 	xul.dll	nsOutlookCompose::ComposeTheMessage(int, CMapiMessage&, nsIFile**)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookCompose.cpp:259
15 	xul.dll	nsOutlookCompose::ProcessMessage(int, CMapiMessage&, nsIOutputStream*)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookCompose.cpp:462
16 	xul.dll	nsOutlookMail::ImportMessage(IMessage*, nsIOutputStream*, int)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookMail.cpp:465
17 	xul.dll	nsOutlookMail::ImportMailbox(unsigned int*, bool*, int, wchar_t const*, nsIMsgFolder*, int*)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookMail.cpp:424
18 	xul.dll	ImportOutlookMailImpl::ImportMailbox(nsIImportMailboxDescriptor*, nsIMsgFolder*, wchar_t**, wchar_t**, bool*)	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/outlook/src/nsOutlookImport.cpp:423
19 	xul.dll	ImportMailThread	c:/builds/moz2_slave/tb-c-cen-w64-ntly-000000000000/build/mailnews/import/src/nsImportMail.cpp:835

Comment 9

[Wayne Mery (:wsmwk)]

also an import crash mozilla::dom::workers::GetCurrentThreadJSContext() bp-b625804a-a903-4b6d-9fa0-f681c2150611

so perhaps all of these?
https://crash-stats.mozilla.com/signature/?product=Thunderbird&version=38.0.1&signature=mozilla%3A%3Adom%3A%3Aworkers%3A%3AGetCurrentThreadJSContext%28%29&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1#comments

Comment 10

[Makoto Kato [:m_kato] (PTO until 5/6)]

XPCOM written by JavaScript has to run on Gecko's main thread.  So both crashes may be same reason that JS based XPCOM tries to run on worker thread for import.

Also, nsOutlookCompose seems to run it on worker thread, so does anyone override "@mozilla.org/messenger/structuredheaders;1" XPCOM that used by nsMsgCompFields?


Wayne, since TB38 will replace MIME parser with JSMIME, we should test outlook and eudora import works correctly on TB38 before released.

Comment 11

[Makoto Kato [:m_kato] (PTO until 5/6)]

Ah, comment #9 seems to be TB38.  outlook and eudora import may not work correctly since replacing with JSMIME.  We should test it.

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to Makoto Kato (:m_kato) from comment #10)
> XPCOM written by JavaScript has to run on Gecko's main thread.  So both
> crashes may be same reason that JS based XPCOM tries to run on worker thread
> for import.
> 
> Also, nsOutlookCompose seems to run it on worker thread, so does anyone
> override "@mozilla.org/messenger/structuredheaders;1" XPCOM that used by
> nsMsgCompFields?
> 
> 
> Wayne, since TB38 will replace MIME parser with JSMIME, we should test
> outlook and eudora import works correctly on TB38 before released.

I haven't tested yet. Perhaps someone else can?


Reminder, crash signature existed prior to version 38 as #25 crash, not #1 as it is in version 38. So bug 858337 (implement header parsing in JSMime) or something else certainly could have just made things worse.

Note also, having this appear in a release suggests we lack enough tests in this area.

Comment 13

[Jorg K (CEST = GMT+2)]

I tried a Eudora Import. Before I did, I needed to apply this registry change, so TB could find the Eudoradata. Of course I do NOT have Eudora installed but I have some old Eudora mailboxes:
=== Registry file, adjust file location as required ===
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Qualcomm\Eudora\CommandLine]
"Current"="Anything H:\\SCRATCH\\Eudoradata Anything"
===

The import crashes in TB 38 and the daily which I compiled myself. The latter gives this:

Hit MOZ_CRASH(nsMsgBrkMBoxStore not thread-safe) at h:/mozilla-source/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp:49
#01: nsMsgIncomingServer::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgincomingserver.cpp:958)
#02: nsMsgDBFolder::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgdbfolder.cpp:743)
#03: nsEudoraMailbox::ImportMailboxUsingTOC (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoramailbox.cpp:379)
#04: nsEudoraMailbox::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoramailbox.cpp:236)
#05: ImportEudoraMailImpl::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoraimport.cpp:542)
#06: ImportMailThread (h:\mozilla-source\comm-central\mailnews\import\src\nsimportmail.cpp:836)
#07: _PR_NativeRunThread (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\threads\combined\pruthr.c:397)
#08: pr_root (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\md\windows\w95thred.c:90)
#09: _get_flsindex[MSVCR120 +0x2c01d]
#10: _get_flsindex[MSVCR120 +0x2c001]
#11: BaseThreadInitThunk[kernel32 +0x1337a]
#12: RtlInitializeExceptionChain[ntdll +0x392e2]
#13: RtlInitializeExceptionChain[ntdll +0x392b5]

Comment 14

[Jorg K (CEST = GMT+2)]

Attachment: Eudora mailbox with one message. That's enough to reproduce the crash.

With this test mailbox, the crash looks a little different:

Hit MOZ_CRASH(nsMsgBrkMBoxStore not thread-safe) at h:/mozilla-source/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp:49
#01: nsMsgIncomingServer::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgincomingserver.cpp:958)
#02: nsMsgDBFolder::GetMsgStore (h:\mozilla-source\comm-central\mailnews\base\util\nsmsgdbfolder.cpp:743)
#03: nsEudoraMailbox::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoramailbox.cpp:288)
#04: ImportEudoraMailImpl::ImportMailbox (h:\mozilla-source\comm-central\mailnews\import\eudora\src\nseudoraimport.cpp:542)
#05: ImportMailThread (h:\mozilla-source\comm-central\mailnews\import\src\nsimportmail.cpp:836)
#06: _PR_NativeRunThread (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\threads\combined\pruthr.c:397)
#07: pr_root (h:\mozilla-source\comm-central\mozilla\nsprpub\pr\src\md\windows\w95thred.c:90)
#08: _get_flsindex[MSVCR120 +0x2c01d]
#09: _get_flsindex[MSVCR120 +0x2c001]
#10: BaseThreadInitThunk[kernel32 +0x1337a]
#11: RtlInitializeExceptionChain[ntdll +0x392e2]
#12: RtlInitializeExceptionChain[ntdll +0x392b5]

Comment 15

[Jorg K (CEST = GMT+2)]

Just as a general note regarding Eudora import:
I use Thunderbird 1.5 (yes, one point five) to do it, and I pre-process the data with "Eudora Rescue":
http://kb.mozillazine.org/Importing_from_Eudora_(Thunderbird)#Importing_Eudora_Mail_with_Eudora_Rescue
IMHO we should remove Eudora import from Thunderbird completely because Eudora has been dead for about 10 years now and the import was never any good. Outlook is of course a different story.

Comment 16

[Matt]

(In reply to Jorg K from comment #15)

> IMHO we should remove Eudora import from Thunderbird completely because
> Eudora has been dead for about 10 years now and the import was never any
> good. Outlook is of course a different story.

I agree wholeheartedly.  Almost everyone left n the Eudora camp want to spent significant time in support forums complaining that Thunderbird does not store their attachments in a separate folder,  Thunderbird messes their mailing lists on import and their "Eudora way" of doing things does not work with Thunderbird.  Remove the import and we can add to the relevant knowledgebase article the last version with import in it.

Comment 17

[Jorg K (CEST = GMT+2)]

Moving on to Outlook import. I fired up my old Vista machine which has Outlook 2003 installed.
TB 38 crashes when attempting an Outlook import. This is what the daily version gives before it also crashes:

Hit MOZ_CRASH(nsMsgBrkMBoxStore not thread-safe) at h:/mozilla-source/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp:49
#01: NS_LogInit[xul +0x4c7a1a]
#02: NS_LogInit[xul +0x4aeb08]
#03: NS_LogInit[xul +0x6f47b0]
#04: NS_LogInit[xul +0x6f2546]
#05: NS_LogInit[xul +0x6c4a2e]
#06: PR_MkDir[nss3 +0x288308]
#07: PR_MkDir[nss3 +0x2756bf]
#08: _get_flsindex[MSVCR120 +0x2c01d]
#09: _get_flsindex[MSVCR120 +0x2c001]
#10: BaseThreadInitThunk[kernel32 +0x4d0e9]
#11: RtlInitializeExceptionChain[ntdll +0x419bb]
#12: RtlInitializeExceptionChain[ntdll +0x4198e]

In conclusion: Import is well an truly busted. However, this is new and really doesn't belong in this bug which was raised on 2013. Maybe we should create two new bugs:
1) Eudora import busted, remove from system.
2) Outlook import busted, let's fix it.

Most likely Outlook Express import is also busted, I'd have to fire up an old XP machine to try it. Outlook Express died with Windows XP in April 2014. Perhaps there are still some people who want to get off XP and move to Thunderbird on another platform.

Comment 18

[Jorg K (CEST = GMT+2)]

Moving on to Outlook Express (Windows XP) import: That worked like a charm with TB38, I imported a few mailboxes on an old XP machine. Sorry about the doomsaying from my previous comment ;-)

Comment 19

[Wayne Mery (:wsmwk)]

Crash comments that mention outlook cite:
2000
2003
2007
2010

Can anyone test those for jorgk?

Comment 20

[Jorg K (CEST = GMT+2)]

I have an old Outlook 2000 somewhere, but what's the point?
We know it crashes straight away. Wayne, would you like the raise the bugs as detailed in comment #17:
1) Eudora import busted, remove from system.
2) Outlook import busted, let's fix it.

The crash that is described in this bug is now obscured by the fact that the import doesn't work at all any more since it crashes straight away and consistently in the same way for Eudora and Outlook.

Comment 21

[Jorg K (CEST = GMT+2)]

Wayne, I've added a new bug 1175055 and I'm getting the hell out of this one.

Comment 22

[Wayne Mery (:wsmwk)]

Do we need a separate bug to cover the path issue, coment 6?

Comment 23

[Jorg K (CEST = GMT+2)]

Yes, if the "path issue" is an issue. Comment #6 says: "... but I have not looked ...".

Comment 24

[Matt]

(In reply to Jorg K from comment #23)
> Yes, if the "path issue" is an issue. Comment #6 says: "... but I have not
> looked ...".

I would not recognise it if I did.  But I think the limit will be there by being absent. Windows has the 256 character limit on a path.  So the add for the folder works fine, but when the O/s Is asked for that path it returns a truncated version is my guess.  It may even return a truncated path in the add folder function.

elcamelion

Comment 25

[Matt]

Anje,Vincent,  Have you seen anything regarding path lengths in support?

Comment 26

[Kent James (:rkent)]

The plan is to "fix" this in 38.1.0 by disabling import, and get import working in a subsequent release.

Comment 27

[Kent James (:rkent)]

so let's block 38.2.0 on this.

Comment 28

[Wayne Mery (:wsmwk)]

Import for outlook is reenabled in version 60

Comment 29

[Wayne Mery (:wsmwk)]

Import crash nsXPCWrappedJS::CallMethod bp-16cb8353-5fbf-4a16-8993-27d8c0190103 65.0b1
 0 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp:615
1 	xul.dll	static nsresult PrepareAndDispatch(class nsXPTCStubBase*, unsigned int, unsigned int*, unsigned int*)	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:88
2 	xul.dll	static void SharedStub()	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:110
3 	xul.dll	nsMsgFolderNotificationService::NotifyFolderDeleted(nsIMsgFolder*)	comm/mailnews/base/src/nsMsgFolderNotificationService.cpp:149
4 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3755
5 	xul.dll	static void ImportMailThread(void*)	comm/mailnews/import/src/nsImportMail.cpp:829
6 	nss3.dll	_PR_NativeRunThread	nsprpub/pr/src/threads/combined/pruthr.c:397
7 	nss3.dll	static unsigned int pr_root(void*)	nsprpub/pr/src/md/windows/w95thred.c:137
8 	ucrtbase.dll	_o____lc_collate_cp_func	
9 	kernel32.dll	BaseThreadInitThunk	
10 	mozglue.dll	static void patched_BaseThreadInitThunk(int, void*, void*)	mozglue/build/WindowsDllBlocklist.cpp:715 

Another example is bp-2507222d-464a-46b6-84ec-1fa620181229 60.3.3
 0 	xul.dll	nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)	js/xpconnect/src/XPCWrappedJS.cpp:610
1 	xul.dll	PrepareAndDispatch	xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:85
2 	xul.dll	mozilla::detail::nsTStringRepr<char>::Equals(mozilla::detail::nsTStringRepr<char> const&)	xpcom/string/nsTSubstring.cpp:864
3 	xul.dll	NS_TableDrivenQI(void*, nsID const&, void**, QITableEntry const*)	xpcom/base/nsISupportsImpl.cpp:23
4 	xul.dll	nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**)	xpcom/components/nsComponentManager.cpp:1393
5 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3731
6 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
7 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
8 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
9 	xul.dll	nsMsgDBFolder::RecursiveDelete(bool, nsIMsgWindow*)	comm/mailnews/base/util/nsMsgDBFolder.cpp:3709
10 	xul.dll	ImportMailThread	comm/mailnews/import/src/nsImportMail.cpp:830 

bp-7c02ab14-4e99-4f31-99c4-6fd620181221 has similar stack with ImportMailThread, but oddly doesn't mention import

Comment 30

[Wayne Mery (:wsmwk)]

In version 68., the crash rate for nsXPCWrappedJS::CallMethod has increased 100x (it was also a steady crash for 60.) - (see the graph) https://crash-stats.mozilla.org/signature/?signature=nsXPCWrappedJS%3A%3ACallMethod&date=%3E%3D2019-06-15T15%3A02%3A00.000Z&date=%3C2019-09-15T15%3A02%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=3#graphs

75% of the crashes I sampled have import on the stack. example bp-937b764c-470d-4ade-98e8-50ad30190915

It's not suprising to see an increase in import crashes on a new release - users expect/hope new versions will fix their import problems and give it another try. But 100x is exceptionally high, quite extraordinary.

Comment 32

[Wayne Mery (:wsmwk)]

per bug 1175168 comment 14, most of the import related crashes are gone, probably due to fixing Bug 272292 - unable to import Seamonkey data into Thunderbird - in 78.1.1 (78.1.0 still has the high crash rate)

Most remaining signatures of nsXPCWrappedJS::CallMethod do not have outlook on the stack but a few do
bp-2bae85b8-bbb9-4d36-81e7-7c3c70201229 78.6.0
0 xul.dll nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp:753
1 xul.dll PrepareAndDispatch(nsXPTCStubBase*, unsigned int, unsigned int*, unsigned int*) xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:88
2 xul.dll SharedStub() xpcom/reflect/xptcall/md/win32/xptcstubs.cpp:110
3 xul.dll nsAbOutlookDirectory::ExecuteQuery(_SRestriction&, nsIAbDirSearchListener*, int, int, int) comm/mailnews/addrbook/src/nsAbOutlookDirectory.cpp:941

Comment 33

[Magnus Melin [:mkmelin]]

MOZ_CRASH Reason (Sanitized): MOZ_RELEASE_ASSERT(NS_IsMainThread()) (nsXPCWrappedJS::CallMethod called off main thread), starting off from https://hg.mozilla.org/releases/comm-esr78/file/tip/mailnews/addrbook/src/nsAbOutlookDirectory.cpp#l941

Comment 34

[Wayne Mery (:wsmwk)]

Hard to say, but looks like version 91.3.0 crash rate for nsXPCWrappedJS::AddRef was significantly lower than version 78 (in early November 2021 just before crash-stats stopped accepting TB crash reports)

Crash report: https://crash-stats.mozilla.org/report/index/96caf3d0-4eea-44f7-a083-3b9ac0211109 91.3.0

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(NS_IsMainThread()) (nsXPCWrappedJS::AddRef called off main thread)

Top 10 frames of crashing thread:

0 xul.dll nsXPCWrappedJS::AddRef js/xpconnect/src/XPCWrappedJS.cpp:240
1 xul.dll AddRefThunk ipc/mscom/VTableBuilder.c:22
2 xul.dll nsMsgMailNewsUrl::~nsMsgMailNewsUrl comm/mailnews/base/src/nsMsgMailNewsUrl.cpp:73
3 xul.dll [thunk]: virtual void* __thiscall nsImapUrl::`vector deleting destructor' 
4 xul.dll nsMsgMailNewsUrl::Release comm/mailnews/base/src/nsMsgMailNewsUrl.cpp:81
5 xul.dll nsImapUrl::Release comm/mailnews/imap/src/nsImapUrl.cpp:81
6 xul.dll nsImapProtocol::~nsImapProtocol comm/mailnews/imap/src/nsImapProtocol.cpp:669
7 xul.dll [thunk]: virtual void* __thiscall nsImapProtocol::`vector deleting destructor' 
8 xul.dll mozilla::net::HttpBaseChannel::Release netwerk/protocol/http/HttpBaseChannel.cpp:383
9 xul.dll nsMsgAsyncWriteProtocol::Release comm/mailnews/base/src/nsMsgProtocol.cpp:1153

nsXPCWrappedJS::CallMethod (still) no longer occurs.

Comment 35

[Makoto Kato [:m_kato] (PTO until 5/6)]

nsImapProtocol is no longer destroyed on non-main thread after landing Bug 1742991. So comment #34's crash will be fixed by it.

Comment 36

[Wayne Mery (:wsmwk)]

(In reply to Makoto Kato [:m_kato] from comment #35)

nsImapProtocol is no longer destroyed on non-main thread after landing Bug 1742991. So comment #34's crash will be fixed by it.

Agree, => WFM